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APPLICANTS: Klaus David Gradischnig et al. DOCKET NO: 1 12740-391 
SERIAL NO: GROUP ART UNIT: 

EXAMINER: 

INTERNATIONAL APPLICATION NO: PCT/EP00/04355 

1 0 INTERNATIONAL FILING DATE: 1 5 May 2000 

INVENTION: PROTOCOL DEVICE IN A PROTOCOL SYSTEM FOR 

TRANSMITTING MESSAGES 

Assistant Commissioner for Patents, 
1 5 Washington, D.C. 2023 1 

Sir: 

Please amend the above-identified International Application before entry 
into the National stage before the U.S. Patent and Trademark Office under 35 
20 U.S.C. §371 as follows: 
In the Specification: 

Please replace the Specification of the present application, including the 
Abstract, with the following Substitute Specification: 
SPECIFICATION 
25 TITLE OF THE INVENTION 

PROTOCOL DEVICE IN A PROTOCOL SYSTEM FOR TRANSMITTING 
MESSAGES 
BACKGROUND OF THE INVENTION 
Both user data and monitoring information are transmitted using 
30 communications protocols. In this case, many protocols ensure that the user data is 
transmitted to the receiver complete (that is to say, all transmitted data is also 
received) and with a protected sequence (that is to say, in the correct sequence 
defined by the transmitter). For the user data, this is often done by the transmitter 
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device in the protocol system successively numbering all the user data with a 
sequence number. (Message) packets which contain only monitoring information 
are normally not successively numbered, at least packets with certain classes of 
monitoring information. However, if the monitoring messages are now transmitted 
5 by the lower layer without sequence protection, this can lead to monitoring 
messages overtaking one another. If the fact that this overtaking has taken place is 
not identified, then, for the receiver of monitoring information, instead of working 
with up-to-date monitoring information, which is likewise available to it, it operates 
with obsolete monitoring information since it receives this as if it were up-to-date. 

10 This behavior is generally not critical for that monitoring information which 
confirms message reception, since this information does not become obsolete. 
However, the rejection of current monitoring information which relates to flow 
monitoring (for example, credit information) due to the use of obsolete information 
is critical, since this information becomes obsolete very quickly. Dynamic window 

1 5 sizes, which are defined by the receiver, are particularly affected by this. 

Two definitions have been fixed with regard to flow monitoring. The term a 
"credit," which the receiver of user data messages (referred to as SD-PDUs in 
Q.2110) reserves for the transmitter via a monitoring message in this case, refers to 
the sequence number (contained in Q.21 10 in the parameter N(MR) of a monitoring 

20 message; for example, a STAT-PDU or USTAT-PDU) of that user data message 
which is the first which is no longer accepted by the receiver. The term "window 
size" refers to a number of user data items which the receiver is prepared to accept. 
In this case, the sequence number (contained in Q.21 10, in the parameter N(R) of a 
STAT-PDU or USTAT-PDU) is used as the counting starting point up to which the 

25 receiver has already received and acknowledged all the messages with a lower 
sequence number. 

The present invention describes how the rejection of current control 
information is avoided and, in particular, how existing protocols which do not solve 
this problem can be upgraded so that they do solve this problem. 
30 It could be suggested that this problem need not be dealt with if the lower 

protocol layer guarantees sequence-protected transmission. However, if it is 
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intended to set up a multilink connection using such a layer, then it must also be 
expected that messages will overtake one another in a layer such as this. 

If a restriction is imposed such that the receiver cannot withdraw a credit 
once it has been allocated, then the abovementioned problem easily can be solved 
5 simply by not processing monitoring information which contravenes this rule. This 
corresponds to the solution in the TCP/IP protocol. This also includes the situation 
where the window size is constant. 

A further simple possibility for solving the problem is to successively 
number all the monitoring information and then to treat the monitoring information 
10 in an analogous manner to the user data. However, it is difficult to introduce this 
retrospectively into the protocols, since the message format would generally need to 
be changed for numbering. However, this is generally unacceptable for 
compatibility reasons when upgrading existing protocols. 

The capacity to withdraw the credit is an important characteristic in some 
15 protocols; for example, SSCOP. At the moment, the problem appears to be 
insoluble for protocols such as these. 

SUMMARY OF THE INVENTION 
Pursuant to the teachings of the present invention, the receiver of the 
monitoring message can always decided whether this monitoring message received 
20 by it contains information which is newer than its current information state. It is, 
thus, impossible for older information to overwrite more current information when 
messages overtake one another. 

In order to decide whether information obtained from a received monitoring 
message is newer than the already available information, protocol information 
25 (monitoring information which is used for monitoring the user data messages, for 
example confirming reception of user data messages, indicating that user data 
messages have not been received or containing the sequence number of that 
message up to which all messages have been received without any gaps) is used, 
provided this is possible. If the transmission sequence cannot be reconstructed on 
30 the basis of the protocol information contained in the monitoring messages, then the 
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only monitoring information items which are additionally successively numbered 

are those for which this is absolutely essential, and which allow such introduction. 

One special feature of the present invention is the skillful combination of a 

message format change which is compatible with the existing protocol, with 
5 analysis of the protocol, in order to allow the receiver of the monitoring information 

to reconstruct the time sequence of transmission of the monitoring information. It 

is thus possible to reject old information. 

Additional features and advantages of the present invention are described in, 

and will be apparent from, the following Detailed Description of the Invention and 
10 the Figures. 

BRIEF DESCRIPTION OF THE FIGURES 
Figure 1 shows a table of protocol information in a monitoring message in 
connection with the teachings of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 
15 The following text describes three exemplary embodiments, which are all 

based on the SSCOP protocol. SSCOP, defined in Q.21 10, assumes that the lower 
layer transmits the data with sequence protection. As discussed above, the problem 
under discussion does not occur here. However, SSCOP is at present being 
upgraded in order to have multilink compatibility and to function via a lower layer, 
20 which does not ensure sequence-protected transmission. This corresponds to the 
MSSCOP (the draft Q.21 1 1 at the Standard before the start of the meeting of ITU- 
T-working party 5/1 1 and the notice of the Study Questionnaire 15/11, Washington, 
June 28 to July 1, 1999), as is currently being discussed in the ITU. However, the 
problem under discussion here is not solved there. 
25 Exemplary Embodiment 1 : 

The simplest method consists of no longer having the capability to reduce 
the credit in the MSSCOP. However, this represents a major restriction of the 
protocol. On receiving a STAT-PDU, the credit information would be rejected if 
the received credit were less than the current credit. 
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Exemplary Embodiment 2 : 

In the MSSCOP protocol (the draft Q.2111 at the Standard before the start 
of the meeting of ITU-T-working party 5/11 and the notice of the Study 
Questionnaire 15/11, Washington, June 28 to July 1, 1999), as is currently under 
5 discussion, the transmission sequence can be reconstructed only from the protocol 
information in the STAT-PDUs and USTAT-PDUs. No message format need be 
changed in this exemplary embodiment. 

In SSCOP, the transmitter (of the user data) uses the protocol information 
which is contained in the list elements and in the parameter N(R) of the received 
10 STAT- and USTAT-PDUs as follows: 

When already transmitted user data messages are confirmed by list elements 
or the parameter N(R) of the received STAT- and USTAT-PDUs without any gaps 
up to a specific sequence number, the variable VT(A) of the transmitter is changed 
such that it once again contains the value of the next ("oldest") message to be 
1 5 confirmed. 

Furthermore, the information in the list elements is used to decide whether 
certain messages in the transmission buffer must be retransmitted or have been 
confirmed by the receiver. The parameter N(R) is also used for the latter. If 
messages have been confirmed, they can be removed from the transmission buffer, 
20 otherwise this is not allowed by the user of the SSCOP. (In this case, the SSCOP 
parameter Clear Buffer has the value FALSE). 

According to the present invention, an additional SSCOP Status Variable 
VT(H) is now introduced for the transmitter. The new variable VT(H) in each case 
stores the largest last list element of all the received STAT-PDUs and USTAT- 
25 PDUs; the last list element in the STAT-PDU indicates the highest SD-PDU 
expected by the receiver, assuming that the STAT-PDU contains any list elements 
at all, and, in a USTAT-PDU, the last list element is used to signal the first SD- 
PDU received after the reception gap signaled by the USTAT-PDU. 

If a received STAT-PDU does not contain any list elements, then the 
30 parameter N(R) contained in the STAT-PDU is used for adaptation of the variable 
VT(H) provided it is greater than the current value of the variable VT(H). It is 
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noted that USTATs always contain two, and only two list elements, which signal 
the gap to be signaled. N(R) in a USTAT is thus always "less" than the list 
elements contained. 

The processing of received POLL-PDUs and STAT-PDUs as well as the 
5 administration of the new status variables VT(H) are based on the following rules: 
When a USTAT-PDU is received, the credit information is rejected if the 
last list element of this message, namely List Element 2 < VT(H). Otherwise, the 
credit information is processed and VT(H) = List Element 2 is set. 

When a STAT-PDU is received, the credit information is rejected if the last 

1 0 list element List Element L < VT(H). Otherwise, the credit information is used and 
VT(H) = List Element L is set. However, if no list element is included, the credit 
information is rejected if N(R) < VT(H), otherwise, the credit information is used 
and VT(H) = N(R) is set. 
Exemplary Embodiment 3 : 

15 Upgrading of the SSCOP and, hence, of the MSSCOP, is currently under 

discussion, to allow the receiver to send a STAT-PDU without this being a direct 
response to a POLL-PDU. (In the MSSCOP, these STAT-PDUs would replace the 
currently defined/discussed CREDIT-PDUs.) This is intended to make it possible 
for the receiver to transmit credit information whenever this appears to be 

20 worthwhile for the receiver. To do this, the receiver generates a STAT-PDU using 
the new credit information. Since the status of the receiver does not need to change 
between the transmission of a number of STAT-PDUs in one poll cycle, and the 
last list element and/or the parameter N(R) may, thus, remain the same, it is 
necessary to successively number the STAT-PDUs in the same poll cycle. This is 

25 done using the STAT sequence numbers. Otherwise, this exemplary embodiment is 
an extension to exemplary embodiment 2. 

The SSCOP-PDU parameters N(SS) and the SSCOP Status Variable 
VR(SS) are introduced. When generating a STAT-PDU, N(SS) is set to the value 
VR(SS). VR(SS) is the next STAT sequence number which is used for 

30 successively numbering the STAT-PDUs within a pole cycle (one poll cycle is the 
time between the reception of two POLL-PDUs). The modified STAT-PDU format 
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is shown in Figure 1. Since N(SS) is written to a field which is currently identified 
as being reserved, an unmodified SSCOP protocol machine can also process such a 
message, since it does not process N(SS). 

If a POLL-PDU with a new poll sequence number is received, then this is 
5 dealt with as normal. The only difference is that, VR(SS) = 0 is also set before a 
STAT-PDU is generated. If a further STAT-PDU is now intended to be generated 
within one poll cycle, in order to modify the credit, then this is done only if VR(SS) 
< 255. Otherwise, no such STAT-PDU is generated. (However, this is an 
acceptable restriction and is in any case better than not allowing any spontaneous 
10 modification of the credit at all.) If VR(SS) < 255, VR(SS) is incremented by 1, and 
a STAT-PDU is then generated. 

Furthermore, two further SSCOP Status Variables are also required: 

• VT(SS), this is the STAT sequence number of the most recently 
received STAT-PDU in the current poll cycle, or 0 if none has 

1 5 yet been received. 

• VT(H), this is the greatest last list element of all the received 
STAT-PDUs and USTAT-PDUS. 

The processing of received POLL-PDUs and STAT-PDUs as well as the 
administration of these new status variables are based on the following rules: 
20 When a USTAT-PDU is received, then the credit information is rejected if 

the List Element 2 < VT(H). Otherwise, the credit information is processed, and 
VT(H) = List Element 2 is set. 

When a STAT-PDU is received, then VT(SS) = 0 is set, provided VT(PA) < 

N(PS). 

25 If, now, N(SS) < VT(SS), then the credit information is rejected. 

If N(SS) > VT(SS) then VT(SS) = N(SS) is set, and the credit information is 
rejected if the last list element is L < VT(H). Otherwise, the credit information is 
used and VT(H) = List Element L is set. 

Although the present invention has been described with reference to specific 
30 embodiments, those of skill in the art will recognize that changes may be made 
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thereto without departing from the spirit and scope of the invention as set forth in 
the hereafter appended claims. 
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ABSTRACT OF THE DISCLOSURE 
A protocol device in a protocol system for transmitting messages wherein both user 
data and monitoring information are transmitted in communication protocols. 
5 While (message) packets with user data are successively numbered in many 
protocols, thus ensuring that the user data are transmitted completely and with a 
protected sequence to the receiver, messages which contain only monitoring 
information are not normally successively numbered. This situation can lead to 
monitoring messages being overtaken, and thus to the rejection of current 
10 monitoring information. The present device addresses how the rejection of current 
monitoring information can be avoided. 
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In the Claims: 

On page 10, cancel line 1 and substitute the following left-hand justified 
heading therefore: 
5 CLAIMS 

Please cancel claims 1-3, without prejudice, and substitute the following 
claims therefore: 

4. A protocol device in a protocol system for transmitting messages, 
comprising: 

10 a part for determining, based on protocol information which is 

contained in a monitoring message received by the protocol device, whether the 
monitoring message contains information which is newer than a current information 
state in the protocol device; and 

a part for updating, if necessary, the information state based on the 

15 determination. 

5. A protocol device in a protocol system for transmitting messages as 
claimed in claim 4, wherein the protocol device additionally successively numbers 
received monitoring messages for which it cannot reconstruct a sequence of the 

20 received monitoring messages based on the protocol information. 

6. A protocol device in a protocol system for transmitting messages as 
claimed in claim 4, wherein the monitoring messages are messages for flow 
monitoring. 

25 

REMARKS 

The present amendment makes editorial changes and corrects typographical 
errors in the specification, which includes the Abstract, in order to conform the 
specification to the requirements of United States Patent Practice. No new matter is 
30 added thereby. 
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Attached hereto is a marked-up version of the changes made to the 
specification and claims by the current amendment. The attached page is captioned 
" Versions with Markings to Show Changes Made." 

In addition, the present amendment cancels original claims 1-3 in favor of 



crossing out underlining which would have been necessary in claims 1-3 in order to 
present those claims in accordance with preferred United States Patent Practice 
would have been too extensive, and thus would have been too burdensome. The 
present amendment is intended for clarification purposes only and not for 
substantial reasons related to patentability pursuant to 35 U.S.C. §§101, 102, 103 or 
1 12. Indeed, the cancellation of claims 1-3 does not constitute an intent on the part 
of the Applicants to surrender any of the subject matter of claims 1-3. 
Early consideration on the merits is respectfully requested. 



new claims 4-6. Claims 4-6 have been presented solely because the revisions by 



Respectfully submitted, 




William E. Vaughn 
Reg. No. 39,05<K 
P.O. Box 1135 
Chicago, Illinois 60690-1 135 
Phone: (312) 807-4292 
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VERSION WITH MARKINGS TO SHOW CHANGES MADE 
In the Specification: 

SPECIFICATION 
TITLE OF THE INVENTION 
5 PROTOCOL DEVICE IN A PROTOCOL SYSTEM FOR TRANSMITTING 

MESSAGES 

D o scription 

Protocol devic e in a protocol system for transmitting mes s ag e s 

4^ What technical problem is your invention intended to s olv e ? 

10 2-. How has the problem been solved until now? 

3, In what way do e s your invention solv e said technical probl e m (have you 

indicat e d the advantag e s)? 

4-. What is th e special f e atur e of the invention? 

Exemplary embodiment or embodim e nts of the invention. 

15 BACKGROUND OF THE INVENTION 

Both user data and monitoring information are transmitted using 
communications protocols. In this case, many protocols ensure that the user data is 
transmitted to the receiver complete (that is to say 2 all transmitted data is also 

20 received) and with a protected sequence (that is to say^ in the correct sequence 
defined by the transmitter). For the user data, this is often done by the transmitter 
device in the protocol system successively numbering all the user data with a 
sequence number. (Message) packets which contain only monitoring information 
are normally not successively numbered, at least packets with certain classes of 

25 monitoring information. However, if the monitoring messages are now transmitted 
by the lower layer without sequence protection theft,, this can lead to monitoring 
messages overtaking one another. If the fact that this overtaking has taken place is 
not identified, this m e ans then , for the receiver of monitoring information, that? 
instead of working with up-to-date monitoring information, which is likewise 

30 available to it, it operates with obsolete monitoring information since it receives 
this as if it were up-to-date. This behavior is generally not critical for that 
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monitoring information which confirms message reception, since this information 
does not become obsolete. However, the rejection of current monitoring 
information which relates to flow monitoring (for example i credit information) due 
to the use of obsolete information is critical, since this information becomes 
obsolete very quickly. Dynamic window sizes, which are defined by the receiver, 
are particularly affected by this. 

Two definitions have been fixed with regard to flow monitoring. The term a 
"credit," which the receiver of user data messages (referred to as SD-PDUs in 
Q.21 10) reserves for the transmitter via a monitoring message in this case means , 
refers to the sequence number (contained in Q.21 10 in the parameter N(MR) of a 
monitoring message- for example an^_a STAT-PDU or USTAT-PDU) of that user 
data message which is the first which is no longer accepted by the receiver. The 
term means"window size " refers to a number of user data items which the receiver 
is prepared to accept. In this case, the sequence number (contained in Q.21 10, in 
the parameter N(R) of an a STAT-PDU or USTAT-PDU) is used as the counting 
starting point up to which the receiver has already received and acknowledged all 
the messages with a lower sequence number. 

The present invention now describes how the rejection of current control 
information is avoided . This d e scribes and, in particular, how existing protocols 
which do not solve the this problem can be upgraded so that they do solve this 
problem. 

It could be suggested that this problem need not be dealt with if the lower 
protocol layer guarantees sequence-protected transmission. However, if it is 
intended to set up a multilink connection using such a layer, then it must also be 
expected that messages will overtake one another in a layer such as this. 

If a restriction is imposed such that the receiver cannot withdraw a credit 
once again once it has been allocated, then the abovementioned problem can easily 
can be solved simply by not processing monitoring information which contravenes 
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this rule. This corresponds to the solution in the TCP/IP protocol. This also 
includes the situation where the window size is constant. 

A further simple possibility for solving the problem is to successively 
number all the monitoring information and then to treat the monitoring information 
5 in an analogous manner to the user data. However, it is difficult to introduce this 
retrospectively into the protocols, since the message format would generally need to 
be changed for numbering. However, this is generally unacceptable for 
compatibility reasons when upgrading existing protocols. 

The capacity to withdraw the credit is an important characteristic in some 
10 protocols^ for example, SSCOP. At the moment, the problem appears to be 
insoluble for protocols such as these. 

SUMMARY OF THE INVENTION 

In the case of the solution sp e cified here Pursuant to the teachings of the 
15 present invention , the receiver of the monitoring message can always decided 
whether this monitoring message received by it contains information which is 
newer than its current information state. It is, thus, impossible for older 
information to overwrite more current information when messages overtake one 
another. 

20 In order to decide whether information obtained from a received monitoring 

message is newer than the already available information . Protocol , protocol 
information (monitoring information which is used for monitoring the user data 
messages, for example confirming reception of user data messages, indicating that 
user data messages have not been received or containing the sequence number of 

25 that message up to which all messages have been received without any gaps) is 
used, provided this is possible. If the transmission sequence cannot be 
reconstructed on the basis of the protocol information contained in the monitoring 
messages, th e n th e only monitoring m e ssages, then the only monitoring information 
items which are additionally successively numb e r numbered are those for which 

30 this is absolutely essential, and which allow such introduction. 
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One special feature of the present invention is the skillful combination of a 
message format change which is compatible with the existing protocol, with 
analysis of the protocol, in order to allow the receiver of the monitoring information 
to reconstruct the time sequence of transmission of the monitoring information. It 
5 is thus possible to reject old information. 

Additional features and advantages of the present invention are described in, 
and will be apparent from, the following Detailed Description of the Invention and 
the Figures. 

BRIEF DESCRIPTION OF THE FIGURES 
10 Figure 1 shows a table of protocol information in a monitoring message in 

connection with the teachings of the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The following text describes three exemplary embodiments, which are all 

15 based on the SSCOP protocol. SSCOP, defined in Q.21 10, assumes that the lower 
layer transmits the data with sequence protection. As discussed in 1 above , the 
problem under discussion thus does not occur here. However, SSCOP is at present 
being upgraded in order to have multilink compatibility and to function via a lower 
layer, which does not ensure sequence-protected transmission. This corresponds to 

20 the MSSCOP (the draft Q.21 11 at' the Standard before the start of the meeting of 
ITU-T-working party 5/11 and the notice of the Study Questionnaire 15/11, 
Washington, June 28 to July 1, 1999), as is currently being discussed in the ITU. 
However, the problem under discussion here is not solved there. 
Exemplary Embodiment 1 : 

25 The simplest method consists of no longer having the capability to reduce 

the credit in the MSSCOP. However, this represents a major restriction of the 
protocol. On receiving an a STAT-PDU, the credit information would be rejected 
if the received credit were less than the current credit. 
Exemplary Embodiment 2 : 

30 In the MSSCOP protocol (the draft Q.21 1 1 at the Standard before the start 

of the meeting of ITU-T-working party 5/11 and the notice of the Study 
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Questionnaire 15/11, Washington, June 28 to July 1, 1999), as is currently under 
discussion, the transmission sequence can be reconstructed only from the protocol 
information in the STAT-PDUs and USTAT-PDUs. No message format need be 
changed in this exemplary embodiment. 
5 In SSCOP, the transmitter (of the user data) uses the protocol information 

which is contained in the list elements and in the parameter N(R) of the received 
STAT- and USTAT-PDUs as follows: 

When already transmitted user data messages are confirmed by list elements 
or the parameter N(R) of the received STAT- and USTAT-PDUs without any gaps 
10 up to a specific sequence number, the variable VT(A) of the transmitter is changed 
such that it once again contains the value of the next ("oldest") message to be 
confirmed. 

Furthermore, the information in the list elements is used to decide whether 
certain messages in the transmission buffer must be retransmitted or have been 

15 confirmed by the receiver. The parameter N(R) is also used for the latter. If 
messages have been confirmed, they can be removed from the transmission buffer, 
otherwise this is not allowed by the user of the SSCOP. (In this case, the SSCOP 
parameter Clear Buffer has the value FALSE). 

According to the present invention, an additional SSCOP Status Variable 

20 VT(H) is now introduced for the transmitter. The new variable VT(H) in each case 
stores the largest last list element of all the received STAT-PDUs and USTAT- 
PDUs(; the last list element in the STAT-PDU indicates the highest SD-PDU 
expected by the receiver, assuming that the STAT-PDU contains any list elements 
at all, and, in an a USTAT-PDU, the last list element is used to signal the first SD- 

25 PDU received after the reception gap signaled by the USTAT-PDU. 

If a received STAT-PDU does not contain any list elements, then the 
parameter N(R) contained in the STAT-PDU is used for adaptation of the variable 
VT(H) provided it is greater than the current value of the variable VT(H)fNe4e^. It 
is noted that USTATs always contain two, and only two list elements, which signal 

30 the gap to be signaled. N(R) in a USTAT is thus always "less" than the list 
elements contained. 
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The processing of received POLL-PDUs and STAT-PDUs as well as the 
administration of the new status variables VT(H) are based on the following rules: 

When an a USTAT-PDU is received, then the credit information is rejected 
if the last list element of this message, namely List Element 2 < VT(H). Otherwise, 
5 the credit information is processed and VT(H) = List Element 2 is set. 

When an a STAT-PDU is received, the credit information is rejected if the 
last list element List Element L < VT(H). Otherwise, the credit information is used 
and VT(H) = List Element L is set. However, if no list element is included, the 
credit information is rejected if N(R) < VT(H), otherwise, the credit information is 

1 0 used and VT(H) = N(R) is set. 
Exemplary Embodiment 3 : 

Upgrading of the SSCOP and s hence also, of the MSSCOP, is currently 
under discussion, to allow the receiver to send an a STAT-PDU without this being a 
direct response to a POLL-PDU. (In the MSSCOP, these STAT-PDUs would 

15 replace the currently defined/discussed CREDIT-PDUs.) This is intended to make it 
possible for the receiver to transmit credit information whenever this appears to be 
worthwhile for the receiver. To do this, the receiver generates an a STAT-PDU 
using the new credit information. Since the status of the receiver does not need to 
change between the transmission of a number of STAT- PDU PDUs in one poll 

20 cycle, and the last list element and/or the parameter N(R) may,, thus., remain the 
same, it is necessary to successively number the STAT-PDUs in the same poll 
cycle. This is done using the STAT sequence numbers. Otherwise, this exemplary 
embodiment is an extension to exemplary embodiment 2. 

The SSCOP-PDU parameters N(SS) and the SSCOP Status Variable 

25 VR(SS) are introduced. When generating an a STAT-PDU, N(SS) is set to the 
value VR(SS). VR(SS) is the next STAT sequence number which is used for 
successively numbering the STAT-PDUs within a pole cycle (one poll cycle is the 
time between the reception of two POLL-PDUs). The modified STAT-PDU format 
is shown in Figure 1. Since N(SS) is written to a field which is currently identified 

30 as being reserved, an unmodified SSCOP protocol machine can also process such a 
message, since it does not process N(SS). 
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If a POLL-PDU with a new poll sequence number is received, then this is 
dealt with as normal. The only difference is that, VR(SS) = 0 is also set before an a 
STAT-PDU is generated. If a further STAT-PDU is now intended to be generated 
within one poll cycle, in order to modify the credit, then this is done only if VR(SS) 
5 < 255. Otherwise, no such STAT-PDU is generated. (However, this is an 
acceptable restriction and is in any case better than not allowing any spontaneous 
modification of the credit at all.) If VR(SS) < 255, VR(SS) is incremented by 1, and 
an a STAT-PDU is then generated. 

Furthermore, two further SSCOP Status Variables are also required: 
10 • VT(SS), this is the STAT sequence number of the most 

recently received STAT-PDU in the current poll cycle, or 0 if 
none has yet been received. 
• VT(H), this is the greatest last list element of all the received 

STAT-PDUs and USTAT-PDUS. 
15 The processing of received POLL-PDUs and STAT-PDUs as well as the 

administration of these new status variables are based on the following rules: 

When an a USTAT-PDU is received, then the credit information is rejected 
if the List Element 2 < VT(H). Otherwise, the credit information is processed, and 
VT(H) = List Element 2 is set. 
20 When an a STAT-PDU is received, then VT(SS) = 0 is set, provided 

VT(PA) < N(PS). 

If, now, N(SS) < VT(SS), then the credit information is rejected. 
If N(SS) > VT(SS) then VT(SS) = N(SS) is set, and the credit information is 
rejected if the last list element is L < VT(H). Otherwise, the credit information is 
25 used and VT(H) = List Element L is set. 

Although the present invention has been described with refe rence to specific 
embodiments, those of skill in the art will recognize that changes may be made 
thereto without departing from the spirit and scope of the i nvention as set forth in 
the hereafter appended claims. 
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Abstract 

Protocol dovico in a protocol system for transmitting messages 
ABSTRACT OF THE DISCLOSURE 

5 A protocol device in a protocol system for transmitting messages wherein b oth user 
data and monitoring information are transmitted in communication protocols. 
While (message) packets with user data are successively numbered in many 
protocols, thus ensuring that the user data are transmitted completely and with a 
protected sequence to the receiver, messages which contain only monitoring 

10 information are not normally successively numbered. This situation can lead to 
monitoring messages being overtaken, and thus to the rejection of current 
monitoring information. The inv e ntion describes present dev ice addresses how the 
rejection of current monitoring information can be avoided. 
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